home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / urn / urn-archives / urn-ietf.archive.9611 / 000018_owner-urn-ietf _Mon Nov 4 10:14:52 1996.msg < prev    next >
Internet Message Format  |  1997-02-19  |  3KB
  1. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id KAA29344 for urn-ietf-out; Mon, 4 Nov 1996 10:14:52 -0500
  2. Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id KAA29337 for <urn-ietf@services.bunyip.com>; Mon, 4 Nov 1996 10:14:40 -0500
  3. Received: from windrose.omaha.ne.us by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
  4.         id AA22469  (mail destined for urn-ietf@services.bunyip.com); Mon, 4 Nov 96 10:14:38 -0500
  5. Message-Id: <9611041514.AA22469@mocha.bunyip.com>
  6. Received: by privateer.windrose.omaha.ne.us; Mon Nov  4 09:13 CST 1996
  7. From: "Ryan Moats" <jayhawk@ds.internic.net>
  8. To: "Martin J Duerst" <mduerst@ifi.unizh.ch>
  9. Cc: "urn-ietf@bunyip.com" <urn-ietf@bunyip.com>
  10. Date: Mon, 04 Nov 96 09:14:28 
  11. Priority: Normal
  12. X-Mailer: PMMail 1.52 For OS/2 UNREGISTERED SHAREWARE
  13. Mime-Version: 1.0
  14. Content-Type: text/plain; charset="us-ascii"
  15. Content-Transfer-Encoding: 7bit
  16. Subject: Re: [URN] %encoding for reserved UTF-8 characters (was: New syntax draft)
  17. Sender: owner-urn-ietf@services.bunyip.com
  18. Precedence: bulk
  19. Reply-To: "Ryan Moats" <jayhawk@ds.internic.net>
  20. Errors-To: owner-urn-ietf@bunyip.com
  21.  
  22. On Mon, 4 Nov 1996 11:50:36 +0100 (MET), Martin J Duerst wrote:
  23.  
  24. >Ryan Moats wrote:
  25. >
  26. >>
  27. >>My brain hurts, but I think I finally understand the issue.
  28. >
  29. >Sorry for my long explanations.
  30.  
  31. It wasn't your explanation, it was getting my brain to stop thinking in ASCII
  32. mode and start thinking in more general character mode.  I'll probably still
  33. slip back and forth, since it isn't natural yet...
  34.  
  35. >>Allow me to restate it to see if I'm right:
  36. >>
  37. >>The problem you are talking about arrises if the reserved character has
  38. >>a UTF-8 representation of more than 1 octet.  Then, if we use %encoding
  39. >>to represent the character in a literal use, there is no way of determining
  40. >>from the URN whether the character is being used as a literal character
  41. >>or not. 
  42. >
  43. >Exactly.
  44. >
  45. >
  46. >- Specify that protocols may only reserve 1-octet UTF-8 characters
  47. >    (i.e. ASCII).
  48. >- Specify that protocols have to define their own escaping mechanisms
  49. >    for things beyond ASCII.
  50.  
  51. Having had the weekend to mull this over some more (and seeing that my
  52. mulling was in the right direction...), here are my thoughts:
  53.  
  54. I would add a third solution to the above-- That the syntax draft defines its
  55. own escaping mechanism for things beyond ASCII.  This ensures that URN
  56. resolvers don't have to be re-written just because some new namespace comes
  57. along that wants to reserve some character in some totally different scheme then
  58. all the others currently used.
  59.  
  60. Having said that, I currently lean strongly towards the first solution that Martin has
  61. proposed, as it keeps the syntax document short, doesn't add a new
  62. escaping mechanism (and all the complexity that adds).  To sum up, it just
  63. strikes me as being CLEANER than any other solution. Does anybody
  64. have problems with it being written into the syntax draft?
  65.  
  66. Ryan
  67.